(1) Field of the Invention
The present invention relates to a broadcast receiving terminal which is a recording and reproduction apparatus that accumulates contents and reproduces the accumulated contents. In particular, the present invention relates to a setup for receiving a broadcast signal including content made up of video, audio as well as data such as a program that are multiplexed into the broadcast signal in synchronization with each other and transmitted, and for accumulating the video, audio and data, as well as a setup for executing trick play such as fast-forward and reverse playback of the content while maintaining the synchronization of the video, audio and the data such as a program.
(2) Description of the Related Art
Various contents are included in a broadcast signal sent from a broadcast station Aside from video and audio used in a normal broadcast program, there are cases where data is included in the contents. There are several methods for sending the data, which can be roughly divided into a method of sending the data chronologically and a method of repeatedly sending the data per set interval. In the former method of sending the data chronologically, for example, data that continues over the course of time is sent in sequential order. This method is suitable for sending large amounts of data over a long period of time, but there is a drawback in that data that could not be received at the timing of the sending cannot be received again. On the other hand, in the latter method of repeatedly sending the data at a set interval, the same data is repeatedly sent any number of times during a fixed period. This method has an advantage in that during the period when the same data is being sent, it is acceptable to receive any one of the repeatedly-sent pieces of data, and thus the timing of receiving is not limited. Data broadcast, represented by BML, and file sending through DSMCC data carousel are examples of this method. It is unknown, particularly in broadcast, when a recipient will select a channel and commence reception. In the method of sending the data chronologically, when the start of reception falls behind the timing of the sending and obtainment of the data fails, the data cannot be re-obtained. Therefore, when sending data such as an application program along with video and audio in the broadcast signal, the method of repeatedly sending the data per set interval is favorable.
At present, specifications for receiving a broadcast signal that includes video, audio, and an application program and executing the application program in synchronization with video and audio, as in the above method, have been developed, and are in operation. It is possible to receive the sent application program, load the application program in a terminal, and realize various extra functions by executing the application program, rather than simply viewing the video and audio. This method for sending the application program and capturing the application program in the terminal is also called “downloading”. For example, a specification called Digital Video Broadcasting—Multimedia Home Platform (DVB-MHP) ETSI ES 201812 v1.1.1 (2003-12) has been developed in Europe, and operations according to this specification have already commenced. In addition, OCAP1.0 (Open Cable Application Platform OC-SP-OCAP1.0-I14-050119) specification, which provides the same specification in the cable broadcast environment, is being developed in the U.S., and operations are set to commence in 2005. In these specifications, the application program is written in the Java language. Various Application Programming Interfaces (APIs) for tuning, graphics display, and the like are provided in the terminal, and the Java application program can control those functions by calling the APIs.
In addition, in North America, the OCAP-DVR specification (OC-SP-OCAP-DVR-I01-040524), which is aimed at adding a function for recording and reproducing the contents in the OCAP specification, is being developed. Here, a content (video, audio, application and so on) which is broadcast is recorded and, in addition, the recorded content is reproduced in the same manner as a content which is directly reproduced from the broadcast signal. The direct reproduction of a content from a broadcast signal, without recording, is also referred to as “play”, and reproduction of a recorded content is also referred to as “playback”.
In the OCAP-DVR specification, a scheduled recording API is stipulated, and by using such API, the Java application is able to register a scheduled recording. Based on the scheduled recording registered by the Java program using the scheduled recording API, an OCAP-DVR terminal starts recording at the specified recording start time, and ends the recording at the specified recording end time.
The various functions stipulated by the OCAP and OCAP-DVR specifications are implemented by using devices existing in a terminal. For example, the reproduction of video/audio included in a broadcast signal makes use of devices, namely, a tuner which extracts an individual data stream from the broadcast signal, a TS decoder which retrieves video/audio from a data stream outputted by the tuner, and an AV decoder which decodes the retrieved video/audio and reproduces the decoded result. In other words, it can be said that the capability of a terminal is determined by the devices that the terminal is equipped with. For example, the aforementioned tuner can be used, not only in receiving a broadcast signal and reproducing video and audio, but also during the recording of the broadcast signal. Since the tuner cannot simultaneously extract a plurality of data streams from the broadcast signal, in order to simultaneously execute “audio and video reproduction” as well as “recording” two tuners become necessary. Therefore, in a terminal equipped with only one tuner, simultaneous execution of “audio and video reproduction” as well as “recording” is not possible.
In OCAP-DVR, there are cases where a plurality of Java applications is simultaneously executed. Each of the Java applications operate independently, and both aim to achieve the desired function realization using OCAP and OCAP-DVR stipulated API. For example, it is possible to assume a situation in which a Java application B requests “audio and video reproduction” close to the start time of a scheduled recording made by a Java application A. In such a case, if the terminal is equipped with two tuners, “audio and video reproduction” and “recording” can be executed simultaneously without any particular problems. However, in a terminal having only one tuner, both processes cannot be executed simultaneously as the absolute number of devices is insufficient. In this manner, “the condition in which a requested plurality of processes cannot be executed simultaneously as the absolute number or capacity of devices is insufficient” is generally referred to as “conflict”. This condition does not occur only when there is one tuner. Even in a terminal equipped with two tuners, it is possible that “audio and video reproduction” as well as “recording” of two channels is requested, and indeed, in such case, “conflict” occurs as all processes cannot be executed simultaneously.
Intellectual property defining an algorithm for solving such a “conflict”, particularly a conflict concerning a scheduled recording, already exists. Japanese Patent Application No. 2003-6445 is a patent relating to a device conflict policy in which “a scheduled recording is always prioritized, when a scheduled recording and chasing playback recording are simultaneously requested and device conflict occurs”. By previously deciding on such a policy, the terminal can solve conflict and processing can be advanced with one of either processes being prioritized.
As in the Japanese Patent Application No. 2003-6445, by previously deciding on a policy for solving device conflict involving a scheduled recording, it is possible to determine which process to prioritize, and proceed with the processing. However, this is a terminal-unique policy which is applicable only in the case where device conflict solution is carried out freely and the process to be executed can be decided on within the terminal. A number of Java specifications, such as the OCAP specification and the OCAP-DVR specification, stipulate solution procedures. Here, as a typical example, two types of OCAP-stipulated device conflict solution procedures shall be introduced. It has already been mentioned that an OCAP specification-compliant terminal downloads and executes a Java application included in a broadcast signal. On this terminal, one or more Java applications are simultaneously executed and, as each make use of a Java API in order to realize a desired function; it is possible that a plurality of processes will be requested simultaneously in the terminal. When such a condition arises, and device conflict occurs as the absolute number of devices is insufficient, device conflict solution is carried out.
In the first procedure, device conflict solution is carried out using the priority level of a Java application. In the OCAP specification, each Java application has a unique priority level, and is ranked in such a way that a Java application having a higher priority level is considered as a more important application. As such, in the case where a plurality of Java applications requests a plurality of processes to be carried out simultaneously, the operation requested by the Java application having a higher priority level is preferentially operated.
In the second procedure, a special application decides on the Java application to be prioritized, regardless of the priority level of the Java applications. The OCAP specification defines an application having a particular privilege. This is referred to as a monitor application The monitor application can previously register in the terminal a “callback function for device conflict solution” which is called back by the terminal when device conflict occurs. In the case where this “callback function” is registered, when the terminal detects the occurrence of device conflict, the callback function is called, before the Java application priority level judgment is carried out. This callback function forwards, to the terminal, the identifier of the Java application to be prioritized, as a return value. The terminal executes the process requested by the Java application forwarded as the return value of the callback function, regardless of the priority level set in the Java application per se.
Particularly in the second procedure, the solution of device conflict is entirely left to the monitor application. The terminal only allocates the devices in accordance to the return value returned by the callback function of the monitor application. In other words, the solution policy during the occurrence of device conflict, in this case, can be understood to be controlled by the monitor application, and not by the terminal.
The aforementioned callback function for device conflict solution is implemented by the monitor application. In a certain installation, the Java application priority level may simply be determined within the callback function. Another installation, may present a selection dialog on a screen, and wait one minute for a user's input on which one to prioritize. Yet another installation may present a selection dialog on a screen, and wait indefinitely for a user's input on which one to prioritize. In other words, the terminal cannot predict when the callback function will make a return, and furthermore, the terminal cannot determine which process to prioritize and execute, until the callback function makes a return.
This is a crucial system defect for a scheduled recording. For example, considering the case where “scheduled recording” and “video and audio reproduction” are simultaneously requested by two Java applications and device conflict occurs. At this time, when a callback function for device conflict solution is registered, the terminal must call such callback function, in accordance to the OCAP or OCAP-DVR specification. However, if the callback function does not return a judgment result even at the scheduled recording start time, the terminal has no choice but to wait, neither able to reproduce nor record.
In view of this, the present invention is conceived in view of such problem and has as an object to provide a recording and reproduction apparatus which solves a resource conflict.